Columbia Kermit/kermit.zip/newsgroups/misc.19970326-19970626/000341_news@newsmaster….columbia.edu _Mon Jun 23 19:56:28 1997.msg

Internet Message Format | 2020-01-01 | 9KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA24901
    for <[e-mail]>; Mon, 23 Jun 1997 19:56:28 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA02800
    for kermit.misc@watsun; Mon, 23 Jun 1997 19:56:28 -0400 (EDT)
Path: news.columbia.edu!sol.ctr.columbia.edu!news.uoregon.edu!hammer.uoregon.edu!nntprelay.mathworks.com!howland.erols.net!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Problems using Kermit 95 with COM1 and COM3.
Message-ID: <[e-mail]>
Date: 20 Jun 97 21:32:44 MDT
References: <5odrb1$[e-mail]> <5of0ll$eng$[e-mail]>
Organization: Utah State University
Lines: 114
Xref: news.columbia.edu comp.protocols.kermit.misc:7205

In article <5of0ll$eng$[e-mail]>, [e-mail] (Frank da Cruz) writes:
> In article <5odrb1$[e-mail]>,
> Paul Vieira <[e-mail]> wrote:
> : I have a PC ( NT 4.0) with 3 serial ports (each one is connected to a
> : modem). I made 3 scripts (one for each port) in Kermit 95 to receive
> : files from the outside. The problem is that I can't run the scripts on
> : COM1 and COM3 at the same time, because one of the modems will not
> : work (initialize). I think the problem is related with the IRQ's
> : ( COM1 and COM3 use the same IRQ). How can I resolve this problem?
> :
> This is a canned reply to all queries regarding the use of MS-DOS Kermit
> on Windows 95 and NT, which are coming in at an ever-increasing rate:
>
> MS-DOS Kermit is not recommended or supported for Windows 95 or NT for the
> very good reason that it was not written for those platforms.  It can not
> make network connections, it does not understand long file names, TAPI
> port/modem sharing, and in many cases it cannot find the serial ports or
> modems at all.  It expects to have full control of your PC: memory, video
> adapter, interrupt controller, serial port, network adapter.  This is not
> possible under Windows 95 and NT.  If MS-DOS Kermit works at all in those
> environments, it is an accident, it is risky, and it is very likely to run
> in a degraded mode.
----------
    This is a little unusual, so I hope folks understand what I'm
saying and why.
    MS-DOS Kermit, as the name says, is for MS-DOS. That's fine. It
also runs in Windows 3 and Windows 95, and OS/2, not by accident, it is
not risky, it is not degraded any more than Windows software degrades its
own programs, and I will not stand by idly if such phrases are repeated.
I wish to take this opportunity to put matters back into context and onto
terra firma.
     In fact MSK runs in both Windows versions in heavy production use
at my site and many others. Dyed in the wool advocates of DOS or Windows or
whatever may wish to skip to the next message because what concerns us here
is working with a mixed environment and not an advocacy of one over the other.
As a point of curiosity, Windows itself is an inherently mixed environment,
as many people know, and in the end that has worked to our advantage. There
are many GUI environments, MS Windows being the most wide spread today.
    MSK can use serial ports, as much as Windows allows any DOS window
application to do so, and where problems arise in almost all cases it is
with Windows' handling of the underlying (and faked to MSK) hardware.
Similar difficulties face corresponding Windows programs. Alas, this is
an imperfect world (insert Windows bomb box or DOS A/R/I message here).
    MSK runs great over networks. But, and we need to have folks
understand this technical point, it does not use winsock (which is a
TCP/IP etc stack for pure Windows programs alone). There is an inherent
problem here if MSK uses its internal TCP/IP stack while another such
stack is loaded and both use the same lan adapter (say Ethernet board).
They can't survive unless rather devious and subtile shims are employed
to try sorting out the two streams of traffic. There is one for NDIS v3
(protected mode) work written by Dan Lanciani at Harvard, file ndis3pkt.exe
a copy of which is in directory drivers on netlab2.usu.edu, but I have not
tested it here. Reports on trials would be appreciated.
    MSK runs naturally over ODI and Packet Drivers. To run that way
in Windows we add shim winpkt (in the MSK distribution kit) to do the
Windows adaptation. MSK also support many other varieties of networking
other than TCP/IP, say LAT for example with appropriate commercial drivers.
    Naturally, no DOS program can take advantage of the pure Windows
only features, say TAPI and sundry. For those features one uses appropriate
Windows programs. Similarly, Windows only programs have their limitations.
Discussions on how well a GUI operating environment reflects (emulates
after interception) the real machine could go on and on, often filled
with partial truths and not so accurate assumptions. Generally speaking
MS has done quite an interesting job of emulation and it is difficult to
discover differences with the real hardware. But differences do exist,
as in any mixed environment.
    One place where Windows gets into trouble is if a DOS program
wants to put the video display into say 132 volume mode. Windows may, but
often does not, know about the video mode changes on the adapter. If it
knows it can put the adapter back in graphics mode, else it puts up a
box saying please run in a full screen DOS box. The latter can be better
because it is easier to read and lots faster than drawing letter strokes.
I might add the same applies to drawing graphics: one is better off in a
DOS environment.
    To forstall pointlessly reopening a well discussed topic may I add
a few words on technical support. It costs. Someone spends time and money
on the other end of the telephone/fax/email system to think about a problem
and compose suggested solutions. Every author wishes it weren't so, but there
are bugs now and then, very few to be sure(!), and we want to hear about them
in full detail and quickly. After all, bugs also cost you time and money.
    Long term readers may think back to the many discussions held on the
support topic over the years, so I won't repeat them here. What I would like
to add, however, is human nature says go to the place where one is listened
to, and get any help available. Alas, many times the real problems are not
with the product of the outfit being called, and it is only through kindness
that answers are provided. That's expensive when one comes right down to it
at the end of each month. Many companies cannot afford to bother being nice
to even legit customer questions. Well, the Kermit project can't afford the
expense either, and assistance comes out of the hides of the project members.
    So I would ask readers to be selective about what they ask for when
difficulties arise, and help relieve the burden on a very slimly financed
operation so that the creative people can continue with the creative work.
Please try regular Windows NEWS groups if the problem appears to be the run
of the mill Windows troubles. Please try here in this Kermit-specific NEWS
group when Kermit(s) themselves are the real doubtful item. Similarly, run
of the mill machine setup/configuration/etc questions are better asked of
your colleagues and friends as well as the many PC-specific NEWS groups.
There are many readers in this group who are willing and able to resolve
Kermit questions, and we need their help.
    We have created some first rate user's manuals in the form of the
"Using ... Kermit" books, which are for sale and hence help underwrite
operating expenses. Think of it as voting with your pocketbook, and of
multiplying that vote by not consuming time of the project unnecessarily.
Those books are the front rank of Tech Support tools, and I think they more
than earn back their cost through saving time and human wear and tear. They
also open opportunities for neat things to do.
        I think we make progress if one remembers that DOS and Windows are
different in many ways, yet very similar in others beneath the covers, so
that DOS programs are quite usable in GUI windows in a many cases, and more
effective than Windows programs in some cases.
    As stated at the beginning, this is a mixed environment with
compromises at every turn. Please use what best suits the situation at hand.
What better advice can one give?
    Joe D.